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BACKGROUND 
Field of Iimveinitioini 

The present invention relates generally to the field of computer communications systems. 
More specifically, the present invention relates to the field of managing transaction messages 
between computer systems. 
BaickgroiuMd off the Innvemntioim 

Modem computer systems generally consist of a number of applications working with 
one another to provide services for users. The applications pass messages between one another 
containing information and data needed by the applications to perform various tasks. A single 
communication between the applications, including any messages, protocol handshaking and the 
like is commonly referred to as a transaction. There are many kinds of transactions that are 
performed in modem computing environments. Each type of transaction is generally identified 
by a transaction code (TC). 

One area in which messaging between computer systems is required is where companies 
having existing computing systems, knovm as legacy systems, must communicate with third 
party systems. This situation occurs firequently, for example, in the case of telephone companies 
that have existing legacy systems that must communicate with third party systems to perform 
various tasks, including ordering services, requesting maintenance, checking statuses and 
changing service. 



The third party computers communicate with the telephone company's legacy systems 
through an interface called an application programming interface ("API"). The API provides a 
common set of routines that third party computers can invoke to gain access to the legacy 
systems. The API generally executes on a gateway computer. The gateway computer provides 
communication and security services for the communication between the legacy systems and the 
third party computers. 

After a transaction is complete, whether successfully or unsuccessfully, it is generally 
assigned a status indicator (SI), which indicates the result of the transaction. A transaction 
code/status indicator pair is commonly referred to as a TCSI. The TCSI contains a transaction 
code representative of a particular transaction, and a status indicator indicating the status of the 
transaction. 

An exemplary conventional system for providing communication between a telephone 
company's legacy systems and third party computers through a gateway is shown in Figure 1. 
Specifically, third party computers 1-5 communicate with legacy systems 102 through gateway 
104. In this example, third party computers 3-5 communicate through the Internet 106, whereas 
third party computers 1 and 2 have direct connections to gateway 104. A firewall 109 can be 
provided by gateway 104 to provide security for the legacy systems. 

Third party computers 1-5 query legacy systems 102 for information. Conventionally, 
the request is made by completing a request window or screen displayed to the requester. This 
request window is part of an API 103. To perform the query, a third party computer, for 
example, third party computer 2, issues a data request to legacy systems 102 through gateway 
104. Gateway 104 provides security and request formatting functions for the particular 



transaction. That is, gateway 104 reformats the request into a request that legacy systems 102 
understand. Gateway 104 receives the information requested and formats it into a response that 
the requester (third party computer 2 in this case) understands. In the system shown in figure 1, 
messages between the third party computers 1-5 and gateway 104 conform to the ANSI 
5 standard, ANSI T 1.246- 1999, Telecommunications, Operations, Administration, Maintenance 
and Provisioning (OAM&P) - Information Model and Services for Interfaces between Operations 
Systems across Jurisdictional Boundaries to Support Configuration Management, which is 
incorporated by reference herein in its entirety, 
i^p A significant problem with this communication paradigm is keeping all communicating 

M) computers in conformance with the Tl .246 standard when changes to the standard are requested. 

ru 

This problem occurs because of the magnitude of the updating that is required to effectuate a 
change to the standard. There are a few hundred messages in the standard. Each message can 
have up to 80 fields of data. When a change is requested, all of the fields in all of the messages 

1 

:^ may have to be updated in accordance with the change. 

H Under the Tl .246 standard, transactions are categorized into transaction types. Whether a 

transaction is inbound or outbound is defined with reference to the legacy systems. Thus, 
inbound transactions are those transactions fi-om the third party systems and outbound 
transactions are those transactions to the third party systems. There are five inbound transaction 
types. There can be many outbound message types that correspond to the five inbound message 

20 types. 

For example, when a third party computer sends a request, for example, an ordering 
request, the resulting response can include up to 80 fields. Due to incomplete information, or 
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prior agreement, not all 80 fields need be sent in each response. The aforementioned problem 
arises when, for example, one of the third parties decides to change the information that its 
computer receives in a given response (outbound) transaction. Consequently, even simple 
changes conventionally require a complete revision and re-release of the software executing on 
gateway 104 even though the data elements are defined in the Tl .246 standard. New revisions of 
code require code modification, rebuilding and testing. This is a time consuming and expensive 
process that can take more than four months to complete. 

Thus, there is a need for a system and method for facilitating these changes without 
requiring modification to the software executing on the gateway and its consequent rebuilding 
and testing. 

SUMMARY OF THE INVENTION 

The present invention solves the problems described above by significantly simplifying 
the management of transaction codes and their associated attributes. Rather than statically 
managing the many transaction types and attributes individually in the software, the present 
invention compresses the transaction types using masks. In this manner, attributes for 
transaction types requiring similar treatment are provided that treatment using a single mask 
representation of the transaction type, rather than repeating that information for each of the 
attributes to be afforded common treatment. 

Each mask is a template that can apply to one or a plurality of attributes. An action value 
is associated with each mask. That action value applies to all messages satisfying the mask. The 
masks and associated attributes are stored in a file that is easily accessed and modified by the 
user. 



For example, every outbound transaction includes a TCSI attribute, described above. To 

provide the appropriate mask for every attribute, the prefix "XXXX" replaces the transaction 

type of a conventional system. For example, the present invention replaces the eight lines: 

2312_TCSI = M 
2140_TCSI-M 
2112_TCSI = M 
2317_TCSI = M 
2755_TCSI = M 
2710_TCSI = M 
2804_TCSI = M 

with the single mask line 
XXXX_TCSI = M. 

This compression becomes much more pronounced as the file size increases from eight 
lines to the tens of thousands of lines in conventional transaction type-attribute files. For 
example, consider changing all the TCSI attributes from M to MM. To make this change in a 
conventional system requires searching for all of the TCSI attributes in a file there could be 
literally hundreds — and making the change. Using the present invention, this change is 
accomplished virtually instantaneously by changing a single line, XXXX TCSI = MM. Thus, 
the present invention significantly facilitates managing transaction types and responding to 
changing requirements. Thus, the present invention eliminates the need for software rebuilds and 
code testing to implement changes. 

In one embodiment, the present invention is a system for managing transactions between 
a first computer system and a second computer system. The system includes a management file 
containing at least one transaction type-attribute string having a mask format with a 




corresponding action value. A process executing on a computer determines what action to take 
in accordance with the at least one transaction type-attribute string. 

In another embodiment, the present invention is a method for managing transactions 
between a first computer system and a second computer system. The method includes the steps 
5 of creating a manager file containing at least one transaction type attribute string having a 

masked format and a corresponding action value. At some point an inbound transaction request 
is received. The inbound transaction request is processed. A response transaction type-attribute 
string having an appropriate attribute for responding to the inbound transaction request is 
determined. The method then performs the step of determining if the response transaction type- 
W attribute string matches one of the at least one transaction type-attribute strings in the manager 

:3 file. If a match is found, the method performs the step of responding to the input transaction 

lU 

request in accordance with the action value associated with the action value corresponding to the 
transaction type-attribute string that matched the response transaction type-attribute string. 

iin Thus, one object of the present invention is to facilitate management of TCSI codes. 

lis Another object of the present invention is to facilitate responding to changing TCSI code 

requirements. 

Another object of the present invention is to reduce the file size and memory 
requirements for storing TCSI codes. 

Another object of the present invention is to ease updating and maintenance of files used 
20 to store TCSI codes. 

Another object of the present invention is to reduce the likelihood of errors generated by 
changing TCSI code requirements. 
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Another object of the present invention is to reduce the time required to react to changing 
TCSI code requirements. 

These and other objects of the present invention are described in greater detail in the 
detailed description of the invention, the appended drawings and the attached claims. 
5 BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic diagram of a prior art system for providing transaction processing 
between computer systems. 

Figure lA is a schematic diagram of a system for providing transaction procession 

Q 

:.g between computer systems according to a preferred embodiment of the present invention. 
Figure 2A is a list of exemplary transaction codes. 

ru 

Figure 2B is a timeline scenario of events resulting in failure using conventional systems. 
Figure 2C is a timeline scenario of events according to a preferred embodiment of the 
present invention. 

^ Figure 3 is an exemplary management file according to a preferred embodiment of the 

Q 

present invention. 

Figure 4 illustrates exemplary masks according to a preferred embodiment of the present 
invention. 

Figure 5 is flow diagram of a process for transaction processing between computer 
systems according to a preferred embodiment of the present invention. 
20 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention is a message manager for managing transaction messages between 
legacy systems at a telephone company and third party requesters through a gateway. For 
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example, such messages include request messages from third party requesters and response 
messages from legacy systems. Figure lA is a schematic diagram of a system incorporating a 
preferred embodiment of the present invention. The system in Figure 1 A is similar to the system 
in Figure 1, but adds a process 105 and a data structure, or table, 107 that is stored in a computer 
memory. The data structure is a transaction code manager file. Briefly, when a third party 
computer makes a request of the legacy systems, process 105 analyzes the request to determine 
the proper format for a response to the request. To make the determination, process 105 consults 
table 107. Table 107 contains masked transaction code-attribute string pairs that facilitate 
managing and modifying the transaction code-attribute pairs. Process 105 and table 107 are 
described in greater detail below. 

Figure 2A illustrates the fields that might be sent back in an exemplary legacy system 
response message (outbound transaction) 200 that can be sent in response to an inbound 
transaction from a third party. For example, the response message can correspond to a 
transaction code of 21 and a status indicator of 12. It would be apparent to those skilled in the art 
that the present invention applies to all transaction codes and status indicators that might be 
encountered. 

Figure 2B presents a scenario using the transaction code illustrated in Figure 2A that 
could occur in a prior art system. Assume for example that on date 1, e.g. August 2"^ response 
message 200 includes a working telephone number (WTN) field as shovra in Figure 2B. On a 
later date, date 2, for example August 14^^, a request is submitted to change the T 1.246 standard 
to set the WTN field to 0. An implementation date, for example September 30*^ is set for when 
the change is to be officially implemented. However, for a variety of reasons, the official date is 
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I 



not always when the change is implemented. For example, the third party may implement the 



change late, for example on November 2""*. Because the response message includes the WTN 



field set to 0, the third party's system will likely malfianction if it expects to see values other than 



all zeroes in the WTN field. Alternatively, the third party might implement the change early, for 



5 example on September 15**". In this case, the third party's system may not function correctly 



because it is expecting to see the WTN field set to 0, and it is not. 



Figure 2C presents a scenario using the transaction code illustrated in Figure 2A 



according to a system employing the message manager of the preferred embodiment of the 



;,p present invention. As before on date 1 (August 2""*) response message 200 includes a working 
it) telephone number (WTN) field as shown. On a later date, date 2, for example August 14*, a 

rU 

i y request is submitted to change the standard to set the WTN field to 0. In this case, a manager file 
(described below) is updated to reflect the change request even though the change has not yet 
been implemented in the system on date 3, for example August 15*\ A manager file is created 



:|J for each outbound transaction type. When a transaction code is encountered, the transaction file 
corresponding to the transaction code is consulted to determine how to respond to the 



transaction. On date 4, November 2"^, the new release of the standard is implemented. Thus, on 



September 30**", when the WTN field is set to 0, there is no disruption of service because the 



manager file is consulted and knows how to handle the transaction code. 



Figure 3 illustrates an exemplary manager file 300 according to a preferred embodiment 



20 of the present invention. Manager file 300 removes the hard coding of transaction type field 



found in the messaging software of conventional systems. According to the preferred 



embodiment of the present invention, transaction type fields are stored in a manger file 300, 
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along with a corresponding action to be taken when each field is encountered. Preferably, 
manager file 300 is loaded into a manager table residing in computer memory at runtime. 

Manager file 300 contains a list of transaction type-attribute strings. Associated with 
each transaction type-attribute string is a requirement for the attribute in the transaction type. For 
5 example, in Figure 3, the transaction type-attribute string "21 12_TCSr' has the action value M. 
This means that for a 21 12 transaction, a TCSI attribute is mandatory. The possible transaction 
types are well-known to those skilled in the art and can be found in the T 1.246 standard 
referenced above. 

p A list of requirement values according to the preferred embodiment of the present 

iW) invention is given in Table I. 

'A Table I: Transaction type-field requirement values 



Requirement 


Meaning 


M 


Mandatory - The attribute must be present in 
the transaction message. 


MZ 


Zeroes - Set attribute to "zeroes" if there is no 
data already present. 


FZ 


Force Zeroes - The attribute must be set to zero 
no matter the response data. 


MM 


Mirror Maybe - Return what is in the request 
(invoke) message if there is no data already 
present in the original return data. 


FM 


Force Mirror - Always return what is in the 
request (invoke) message. 


FS 


Force Space - Set attribute to "spaces" always. 


B 


Blanks -Attribute may be a blank (space) that 
means something. 


N 


Not Sent - Do not send attribute. 


Y 


Sent - Send attribute. This is typically the 
default case. 



-10- 



MS 


Set attribute to "spaces" if there is no data 




already present 



Exemplary transaction type-attribute entries and corresponding attribute requirements 
values for 3 transaction types, 2112, 2311 and 2140, stored in manager file 300 are shown in 
Figure 3. In T 1.246 messaging, there are approximately 200 transaction types. As described 

5 above each transaction type has 80 attributes. Thus, manager file 300 could have more than 
16000 entries if all entries are populated. As a result, its management is a time-consuming, 
costly and cumbersome task that is prone to error. For example, to change a value for all TCSI 

"I fields, the operator must search for the TCSI field in every translation type. 

"'hi 

i=» The present invention avoids the need for listing, and consequently, managing every 

ru 

W transaction type and every attribute, by using substitution masks. The substitution masks are 

[ essentially global place holders that values are substituted for. Figure 4 shows an exemplary use 
of the masks of the present invention. Referring to Figure 4, there is shown a manager file 402 

^ having 3 transaction type-attribute strings 404, 406 and 408. 

If a request comes in requiring a 2317 response for the ZIP2 attribute, software according 

15 to the present invention, executing on a computer such as gateway 104, consults manager file 
402 to try to find a transaction type-attribute string having a value of "2317_ZIP2." In this case, 
process 105 finds the transaction type-attribute string 404. Process 105 obtains the requirement 
value associated with transaction type-attribute string 404 (B in this case) and performs the 
appropriate action for that requirement value. 

20 If a request comes in requiring a 2317 response for the ZIPl attribute, software according 

to the present invention, executing on a computer such as gateway 104, consults manager file 
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402 to try to find a transaction type-attribute string "2317_ZIP1." In this case, process 105 does 
not find transaction type-attribute string "2317_ZIP1." When it cannot find the exact transaction 
type-attribute string, process 105 looks for a mask that matches the transaction type-attribute 
string. In this case, process 105 finds transaction string 406 "23XX_ZIP1." The "XX" in 
5 transaction string 406 is the substitution mask. The "XX" can take on any value. That is, the 
transaction type-attribute applies to any transaction type having the first two numbers 23 and, in 
this case, attribute ZIPl. Process 105 obtains the requirement value, MM in this case, and 
performs the appropriate action for that requirement value, 
j'p If a request comes in requiring a 2317 response for the TCSI attribute, process 105 

!M) consults manager file 402 to try to find a transaction type-attribute string "2317_TCSI." In this 

ru 

case, process 105 does not find a transaction type-attribute string "2317_TCSL" When it cannot 
find the exact transaction type-attribute string, process 105 looks for a mask that matches the 
U transaction type-attribute string. In this case, process 105 finds transaction string 408 
i;n "XXXX TCSI." As before, the "XXXX" in transaction string 408 is a substitution mask. The 

•:t=: 

16 "XXXX" can take on any value. In this case, the transaction type-attribute applies to any 
transaction type and, in this case, attribute TCSI. Process 105 obtains the requirement value, M 
in this case, and performs the appropriate action for that requirement value. 

In the preferred embodiment of the present invention, process 105 looks first for a literal 
match, and then looks for matches through masks. In addition, preferably, process 1 05 looks for 

20 the least amount of masking possible. For example, for a request requiring a 2317_ZIP1 
response, process 105 uses the requirement value associated with 23XX_ZIP1, rather than 
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XXXX_ZIP1, if both are present in a manager file. Thus, in the preferred embodiment Hteral 
matches override masked matches. 

It can be seen then that the generic masks of the present invention allow for the 
compression of large numbers of the transaction type-attribute entries into a relatively small 
number of entries. For example, because the TCSI attributes are required for every transaction 
type, providing a transaction type-attribute string "XXXX_TCSI = M" in a manager file 
according to the present invention reduces what conventionally required 200 entries (one for each 
transaction type), to only one entry. The optimization of this compression depends on the 
requirements of the second computer system. 

In the preferred embodiment of the present invention, manager file 300 is loaded into a 
data structure in memory at runtime. This process requires reading each of the transaction type- 
attribute entries along with their corresponding requirement values and storing them in a table in 
a data structure in runtime memory, for example table 107. Creating table 107 from manager file 
300 at runtime would be apparent to those of skill in the art. 

In the preferred embodiment of the present invention, comments can be added to manager 
file 300. Comments can be provided for any purpose, for example, for explanations. In the 
preferred embodiment, comments are indicated by a symbol as the first character of a line in 
manager file 300. 

A flow chart for process 105 according to a preferred embodiment of the present 
invention is illustrated in Figure 5. Referring to Figure 5, when a response, identified by a 
transaction type, is received by gateway 104 fi*om legacy systems 102, process 105, for each 
attribute in the response, first determines if there is a literal match for the attribute and 



-13- 



corresponding transaction type in step 502. If there is such a match, process 105 continues in 
step 504 where it obtains the requirement value associated with the transaction type-attribute 
string and fills in the value of the response in accordance with the requirement value associated 
with the transaction type-attribute string. If there is no literal match, process 105 determines, in 
step 506, whether there is a mask that matches the response. As described above, step 506 tries 
to find the mask that is closest to a literal match. If there is a matching mask, process 105 
continues in step 504 where it obtains the requirement value associated with the transaction type- 
attribute string and fills in the value of the response in accordance with the requirement value 
associated with the transaction type-attribute string. If there is no matching mask, then in step 
508 process 105 indicates that an error has occurred. Whether an appropriate action has been 
taken in step 504 or an error is indicated in step 508, process 105 continues in step 510, where it 
determines if there are any more attributes in the response. If there are more attributes, process 
105 gets the next attribute in step 509. If there are no more attributes process 105 ends in step 
512. 

The message manager of the present invention is primarily related to the outbound 
messages, as inbound messages are not expected to change frequently. However, should this 
assumption prove erroneous, the techniques described herein can be applied to inbound 
transaction messages as well. 

The foregoing disclosure of embodiments of the present invention has been presented for 
purposes of illustration and description. It is not intended to be exhaustive or to limit the 
invention to the precise forms disclosed. Many variations and modifications of the embodiments 
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described herein will be obvious to one of ordinary skill in the art in light of the above 
disclosure. The scope of the invention is to be defined only by the claims appended hereto, and 
by their equivalents. 
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